前言：被擋掉的封包是最便宜的情報

Day 21 我們把整個機房六台核心主機的日誌收進同一個查詢介面，並建立了可比對的 WORM 封存流程 (只寫一次，讀取多次)。今天我們聚焦在網路安全中最常見、卻也最容易被誤解的一種日誌，也就是防火牆擋掉的連線紀錄。

被擋掉的封包情報成本極低，因為阻擋本來就是防火牆的基本職責，產生阻擋日誌只是順手記錄的副產品，但它價值極高，因為每一行拒絕紀錄都代表著「有人企圖連線到一個不該連的地方」。只要掌握來源 IP（Source）、**目的連接埠（Destination Port）與時間戳記（Timestamp）**三個欄位，就能回答大多數的安全疑問。

在最初的架構草稿中，我的預設前提是：

「機房內有四道防火牆，各自將阻擋紀錄送出，再用同一支程式去解析匯總。」

然而實際盤點現場後才發現殘酷的現實，四道牆裡有兩道根本沒開，第三道擋了但不記紀錄，邊界的核心 FortiGate 雖然一直在阻擋，卻預設一筆拒絕都沒記。

因此，本文將分為兩大部分：

1. 現場盤點與排雷：釐清各道牆的現況，探討主機防火牆為什麼不該貿然開啟，並讓沉默的邊界設備開口說話。
2. 分析、報表與監控：統一多源日誌格式、產出週報回答三個關鍵問題，並將日誌轉化為 Prometheus 告警指標。

本日程式碼已整併至 onprem-logs v0.2.0 的 firewall/ 目錄；告警規則則整併至 onprem-metrics v0.2.2。

一、五道牆的現況盤點

經全面清查後，場域內涉及封包過濾的邊界與節點共有五處：

統整三種日誌解析邏輯

雖然日誌來自五個不同位置，但本質上只有三種格式：

1. Netfilter LOG 家族（ufw、pve-firewall、DOCKER-USER）：標準核心格式，包含 SRC= DST= PROTO= DPT=。在 LogsQL 中使用 extract " SRC=<src> " 抽詞。

   注意：抽詞前後必須保留空格，因為網卡 MAC= 欄位的值內部也包含等號，缺少空白邊界會導致解析錯位。

2. FortiGate 結構化日誌：標準 Key-Value 格式，直接調用 LogsQL 內建的 unpack_logfmt 函式。
3. QuLog 連線事件：純文字行，使用「名稱: 值,」的正則模式抽取。

報告分析腳本 fw-report.py 會將這五種來源統一抽象為四個通用欄位：src、dst、proto、dpt，讓後續的分析判讀，能完全解耦於底層來源。

二、主機上的兩道牆為什麼先不開？

在維運中，不變更往往比盲目開啟防護需要更謹慎的工程論證。

1. DGX Spark：ufw 有裝，但維持未啟用

檢視兩台 Spark 的 /etc/ufw/ufw.conf，皆為 ENABLED=no。Day 11 的安全加固僅在容器內驗證，並未套用到實體機器。草稿中的腳本 spark-ufw-logging.sh 在遇到未啟用的 ufw 時會中斷執行，這是正確的行為：「開啟防火牆」是獨立的高風險變更，絕不能混雜在「開啟日誌」的操作中順便執行。

評估是否啟用主機 ufw 的權衡如下：

決策結論：
這兩台機器專注於內網高效能運算與密集測試，且 Docker 服務預設即繞過 ufw，硬開 ufw 防不到容器，反而極易干擾 NCCL 跨機通訊。因此決定不啟用 ufw，防禦重心放在邊界。

作為補償措施，我們建立監聽連接埠基準盤點，spark02 對區網暴露的僅有 22（SSH）、9100（node_exporter）與 mDNS，其餘 15 個 NCCL 臨時 Port 皆嚴格綁定在 CX7 專屬網段（192.168.100.0/24）。這份盤點清單比一道疏於維護的 ufw 更能精準掌握主機暴露面。

2. Proxmox VE：開關在叢集層，且會觸發 Bridge Netfilter 陷阱

原先想規劃「先在節點 A 啟用驗證，順利後再開節點 B」。但深入研讀 PVE 防火牆元件（pve-firewall 6.0.6）文件後，發現不能這樣子搞，原因如下：

1. 開關位於叢集全域層級：cluster.fw 一旦寫入 enable: 1，所有節點將同步載入規則；個別節點的 host.fw 設定 enable: 0 僅會略過該節點的主機防護，無法做到乾淨的單節點隔離測試。
2. 引發 Bridge 封包過濾陷阱：開啟開關會強制將核心參數 net.bridge.bridge-nf-call-iptables 置為 1，導致所有 Linux Bridge（vmbr）轉發的 VM 流量全面經過 Host 的 iptables FORWARD 鏈。
   • pve1 上執行著 Docker，其預設的 FORWARD 鏈 policy 為 DROP。
   • PVE 的放行規則 PVEFW-FORWARD 被附加在 FORWARD 的末端。
   • VM 的新建連線在未經過 Docker 鏈匹配時，會直接落入 Docker 的 policy DROP。而我們的日誌收集端 VM 正好運行在 pve1 上。
3. 管理群組 IPSet 行為過於寬鬆：該架構中的 management IPSet 會強制將整個本機所在網段併入。即便管理者在設定檔中限縮來源範圍，也無法將同網段的其他主機阻擋在 Web UI（8006）與 SSH 之外。

所以不能貿然動 PVE 防火牆：若在 pve2 貿然開啟防火牆，首當其衝斷線的將會是運行在 pve1 上的日誌收集伺服器。

決策結論：
PVE 防火牆暫不開啟，在 pve-firewall.md 中重新定義了正確的啟用程序：

• 必須先在裝有 Docker 的節點之 DOCKER-USER 鏈放行 vmbr0 橋接流量，方可啟用叢集開關。
• 回退停用時，需手動將 net.bridge.bridge-nf-call-iptables 調回 0（系統停用時不會自動還原）。

此外，鏡射日誌的 pvefw-journal.service 也修正了一個隱藏缺陷：原先設定了 LogLevelMax=notice，但這會連帶過濾掉 service 內透過 systemd-cat -p info 寫入的日誌。實測證明，若不拿掉此限制，日誌鏡射服務會無聲無息地丟棄所有阻擋紀錄。

三、邊界：讓 FortiGate 說出它擋了什麼

1. 擋了大量連線，但日誌空空如也

透過 FortiOS REST API 備份並檢視既有政策：

• policy 1（內網往外網全開）：logtraffic 設為 utm，僅記錄觸發安全特徵的連線。
• policy 8（headscale 入站）：設定為 all。
• policy 4（阻擋網路攝影機外連）：設定為 disable（不記錄）。
• 隱含拒絕（Implicit Deny）：記錄開關雖開，但近一週命中計數為 0。
• 外網 WAN 掃描屬於 local-in 流量，因本機無硬碟，local-in-deny-unicast 預設關閉以保護記憶體環狀緩衝區。

同時也找到一個之前沒想過的情況，也就是邊界防火牆每天默默擋下約 6.3 萬次攝影機對外連線，但在日誌系統中完全沒有留痕。 防火牆日誌最常見的失效模式不是解析錯誤，而是根本沒開記錄，而管理者往往誤以為邊界防護一定都有開。

2. 配置 FortiGate 送出 Syslog

FortiGate 支援四組獨立的 Syslog 目的地。為了不影響現有維運，我們啟用 syslogd2：

關鍵設定均由實測驗證：

• 傳輸格式採用 rfc5424：
  實測比對，預設（default）格式缺乏 RFC syslog 標頭，VictoriaLogs 無法解析 hostname，且時間戳記會淪為收集端接收當下的時間；改採 rfc5424 後，hostname 精準帶出設備名稱，_time 保留事件發生當下含時區的時間戳。
• 連線協定採用 TCP（reliable）：
  走 514/TCP 確保可靠傳輸。收集端 DOCKER-USER 必須預先將 FortiGate IP 加入白名單，否則首波日誌將被收集端拒於門外。
• 精準過濾流量分類：
  過濾器僅啟用 forward-traffic 與 local-traffic。原先嘗試使用 category traffic 搭配 include 規則，但實測發現系統仍會發送 type="event"（如 DHCP、無線客戶端狀態）；必須改用 category event 搭配 exclude 才能徹底攔截事件雜訊。

最後，將關鍵的 policy 4 之 logtraffic 由 disable 切換為 all。

3. 第一個小時的觀測數據

規則於 11:42 啟用記錄，隨後一小時（11:42～12:42）收集到的數據如下：

這些紀錄證實了 policy 4 的有效性：攝影機持續不斷嘗試對外校時與回連雲端，在被擋下後未出現繞道行為。更重要的是，第三台攝影機完全沒出現，代表它可能已斷線或變更了 IP，這正是自動化報表應主動告警的異常狀況。

4. 儲存成本估算與 WORM 政策權衡

每小時約 2,920 筆，換算全天約 7 萬行日誌。相較 Day 21 全場域每日 8.3 萬行，日誌總量暴增了 84%。實際儲存空間換算如下：

空間消耗在熱儲存層完全可控（90 天佔用不到 12 GiB 上限的 4%），但我們進行了兩項關鍵最佳化：

1. 過濾高頻低價值的 NTP 封包：
   .121 攝影機每兩秒對 9 台時間伺服器發出 NTP 請求，佔了拒絕量的 65%。在 syslogd2 過濾器中加入 category traffic 的 (service NTP) exclude 規則後，10 分鐘日誌量即從 485 筆降至 186 筆（降幅達 62%）。剩餘的阻擋紀錄全為高價值的 HTTPS 與 DNS，每日日誌量大幅收斂至 2.7 萬行。
2. 阻擋日誌排除於 WORM 封存之外：
   攝影機外連的阻擋紀錄高度重複且不具法令稽核價值，反而涉及設備 MAC 與連線軌跡的最小化保存原則。因此在 archive-day.sh 中新增 ARCHIVE_SKIP 機制。
   在每日產出的 MANIFEST.tsv 中會明確標註：

   # skipped    syslog-fgt-edge    4230    ARCHIVE_SKIP
   

   確保合規稽核時能證明「此來源係依資安政策明確排除，而非日誌管線遺漏遺失」。

查詢阻擋連線的 LogsQL 語法範例如下：

# 查詢 FortiGate 24 小時內阻擋排行
_time:24h hostname:=fgt-edge "type=\"traffic\"" "action=\"deny\""
  | unpack_logfmt from _msg fields (srcip, dstip, dstport, proto, policyid, action)
  | filter action:=deny
  | stats by (srcip, dstip, proto, dstport) count() as n 
  | sort by (n) desc 
  | limit 20

技巧：action 欄位是在 unpack_logfmt 解析後才產生，因此開頭必須先使用原始文字關鍵字 "action=\"deny\"" 進行第一階段管線篩選，後續再透過 filter action:=deny 過濾。若順序顛倒，將查無資料。

四、收集端自身的守備防線（DOCKER-USER）

收集端主機在 Day 21 透過腳本在 DOCKER-USER 鏈掛載了 ONPREM-LOGS 規則。若以手動方式執行 iptables -I 插入 LOG 規則，一旦 onprem-logs-allowlist.service 重啟，整條鏈會被清空重建，手動規則隨即失效。

因此，我們直接在 docker-user-allowlist.sh 內建 LOG_DROPS=1 機制：在每條 DROP 規則前插入條件相同、且具備 6 筆/分鐘限速 的 LOG 規則。

實測非授權來源探測：

1. pve1 企圖連線 514（pve1 僅在 9428 白名單內）。
2. NAS 企圖連線 9428（NAS 僅在 514 白名單內）。

兩次測試均精準攔截並記錄 4 行核心日誌（TCP SYN 逾時重試次數）。本機產生的 journald 上傳走 loopback，不經由 FORWARD 鏈，因此不需特別配置白名單。

此防線在正常運作下應維持零筆紀錄；一旦出現紀錄，即代表有未登錄的主機嘗試送出日誌，或是內網發生橫向探測行為。

五、NAS 連線紀錄：看穿慢速密碼猜測

分析 QuLog 的連線結構，實際動作字串包含 Connection type: SSH/SFTP、HTTP、HTTPS，動作則區分為 Login Success、Logout、Login Fail。三天內 SSH/SFTP 成功登入高達 4,612 次（主要來自 Day 19 收集端每分鐘執行的 Prometheus 採集腳本）；登入失敗僅 2 次，為工程師手動輸入密碼錯誤。

檢視 QNAP 的防護設定（/etc/config/uLinux.conf 中的 [Ban Engine]）：

• 預設阻擋機制：1 分鐘內失敗 5 次，封鎖該 IP 5 分鐘。
• 盲點：攻擊者若採取每分鐘 4 次的慢速字典檔猜測，便永遠不會觸發系統封鎖，但一小時即可嘗試 240 次；即便被封鎖，5 分鐘後解除又可周而復始。

因此，監控告警的門檻定位在捕捉躲過原生防護的慢速滲透：

• 單一來源 1 小時失敗達 10 次：代表存在刻意規避 5 次/分門檻的惡意嘗試。
• 單一來源 1 小時失敗達 50 次：代表 NAS 內建的 Ban Engine 可能故障或被繞過，需立即升級至上游網路層進行攔截。

六、三個問題與自動化週報

報表工具 fw-report.py 從 VictoriaLogs 讀取五種來源的統一資料，專注回答三個關鍵安全問題：

1. 誰在敲門？：各主機阻擋封包依來源 IP 排序。邊界清晰顯示兩台攝影機的持續外連；內網主機若出現異常連線，將一目了然。
2. 敲在哪裡？：連線依通訊協定與目標 Port 排序（腳本自動將數字協定碼轉換為 TCP/UDP）。
3. 誰是新面孔？：比對近 24 小時與**過去 7 天基線（排除近 24 小時）**的來源集合。新出現的來源 IP 將被單獨列出。

實作提醒：在實作基準時間位移時，LogsQL 應寫為 _time:7d offset 24h。開發測試時曾不慎寫反，導致比對區間變成空集合，所有正常設備瞬間全數被判定為「新面孔」。

系統排程於每週一 08:15 自動產出一份 7 天視窗、30 天基線的 Markdown 報表至 /srv/reports/。工程團隊在週會檢視時僅需確認兩件事：

• 告警候選清單：確認應加入白名單、深入追查還是忽略。
• 新面孔名單：核對內部變更工單，無對應工單的新來源即列入資安事件排查。

七、從日誌判讀到 Prometheus 告警

fw-report.py 支援 --textfile 參數，每 10 分鐘執行一次 1 小時時間視窗的統計，並將指標寫入 node_exporter 文字檔目錄。

在 firewall.yml 中配置了六條告警規則：

解決指標靜默失效的盲點

在最初的告警設計中，FwSilent 永遠不會被觸發。因為當某台主機完全沒有日誌時，LogsQL 的 stats by (host) 根本不會回傳該主機的資料列，textfile 內便不會產出該 Series，Prometheus 自然無法對不存在的序列評估 fw_blocked == 0。

解法：
為 fw-report.py 擴充 --expect 參數（例如配置 FW_EXPECT=fortigate:<設備名稱>）。腳本會主動比對預期清單，若名單內的設備在時窗內沒有任何阻擋，主動輸出數值為 0 的指標（fw_blocked 0），確保 Prometheus 能精準捕捉靜默異常。

八、不該變成告警的正常行為（雜訊抑制）

在維運中，學會忽略符合預期的阻擋與找出異常同樣重要：

1. 攝影機規律外連：受 policy 4 攔截是預期防禦，進報表統計但不發出告警，門檻設定在常態流量之上。
2. 收集端對 NAS 的常態探測：Day 19 配置的 nas-textfile.sh 每分鐘會 SSH 連線 NAS 一次，每日產生約 1,440 筆成功登入紀錄。分析連線日誌時需先將該 IP 排除。
3. NAT Hairpin 流量：內網主機透過公網 IP 存取 headscale 時，在 FortiGate 上會產生內部介面進、內部介面出的 Accept 紀錄，此非外部連線，不應誤判。
4. 本機 Loopback 上傳：收集端對 9428 的推送走回環介面，不經由外部網路鏈，無需加入白名單。

九、部署實作指令

1. 收集端配置（白名單與 LOG 啟用）

# 1. 編輯白名單設定檔，將 FortiGate IP 加入 SYSLOG_FROM
sudoedit /etc/default/onprem-logs-allowlist

# 2. 重啟白名單服務（LOG_DROPS 預設已啟用為 1）
sudo systemctl restart onprem-logs-allowlist

# 3. 確保本機 journald 送往收集端
sudo ./node/install-journal-upload.sh http://127.0.0.1:9428

2. FortiGate 配置（CLI 指令）

# 配置 syslogd2 傳輸端點
config log syslogd2 setting
    set status enable
    set server "IP"
    set mode reliable
    set port 514
    set format rfc5424
end

# 配置過濾條件，排除高頻 NTP 與 Event 事件
config log syslogd2 filter
    set forward-traffic enable
    set local-traffic enable
    set multicast-traffic disable
    set sniffer-traffic disable
    set ztna-traffic disable
    set http-transaction disable
    set anomaly disable
    set voip disable
    set forti-switch disable
    config free-style
        edit 1
            set category traffic
            set filter "(service NTP)"
            set filter-type exclude
        next
        edit 2
            set category event
            set filter "(type event)"
            set filter-type exclude
        next
    end
end

3. 自動化報表與定期排程

# 建立報表儲存目錄
sudo install -d -o metrics -g metrics /srv/reports

# 部署 cron 排程（替換為實際 FortiGate 設備名稱）
sed 's/fgt-edge/<FortiGate_Hostname>/' firewall/collector.cron | sudo tee -a /etc/cron.d/onprem-logs

# 手動執行驗證報表產出
VL=http://127.0.0.1:9428 ./firewall/fw-report.py --window 24h --baseline 7d

十、驗證成果與後續規劃

本日已完成驗證項目

• 單元與整合測試：通過 tests/smoke-firewall.sh（驗證五種來源格式解析、非 Deny 忽略、名單內主機零筆補零輸出、NAS 失敗統計）。
• Prometheus 規則驗證：新增四組單元測試案例，通過 promtool test rules 與 promtool check rules。
• 封存機制防禦測試：tests/smoke.sh 驗證 ARCHIVE_SKIP 機制，確認排除的來源不會寫入 WORM，且 MANIFEST.tsv 會正確記錄 skipped 狀態。
• 靜態分析：ShellCheck（0.9.0 / 0.10.0）與 systemd-analyze verify 均無警告。

1. 累積完整一週日誌後，產出首份完整週報，並依據實際 baseline 微調告警門檻數值。
2. 若未來評估啟用 PVE 或 Spark 主機端防火牆，依照已驗證的 SOP 與順序啟用，並確認第一筆 policy DROP: 產生後校正日誌過濾規則。
3. Day 24 規劃導入網頁過濾（Web Filter）日誌時，需於 FortiGate syslogd2 過濾器中來補上對應分類囉。

明天預告

今天我們讓防火牆日誌顯示出「誰在什麼時間去連了哪個連接埠?」，但日誌無法告訴我們「封包內部究竟裝了什麼內容」。

明天 Day 23，我們將前進到底層封包擷取（Packet Capture）。我們將運用最小權限原則在節點上配置 tcpdump，並結合 NAS 內建封包工具，重現並分析 Day 13 發生的 NFS 7分13秒中斷事件與 Day 15 的 corosync 叢集心跳流量，同時將擷取檔案無縫整合進 Day 21 的長期封存管線。

相關資源索引

• 系列文章與專案索引：onprem-ops-30days
• 本日程式碼實作：
  • onprem-logs v0.2.0
  • onprem-metrics v0.2.2
• 官方與技術參考文件：
  • FortiOS 7.6 Log Message Reference — Traffic 日誌欄位結構說明
  • VictoriaLogs Syslog Data Ingestion — RFC 3164 與 RFC 5424 接收規範
  • VictoriaLogs LogsQL unpack_logfmt — 拆解 Key-Value 結構日誌
  • Proxmox VE Firewall Documentation — pvefw-logger 與橋接過濾機制
  • Docker Packet Filtering and Firewalls — DOCKER-USER 鏈與 Netfilter 行為分析